Metadata search based on semantics

ABSTRACT

According to some embodiments, a method and an apparatus of enriching search results with metadata are provided to receive a plurality of metadata associated with an entity and storing the plurality of metadata in a repository. A search request associated with the entity is received and search results that comprise a portion of the plurality of metadata stored in the repository are determined.

BACKGROUND

Traditional search mechanisms are based on keyword matching by creatingindexes on various text elements. Thus, a user can only perform searchesbased on keywords that match data elements contained in an index. Forexample a user may search for “Quarterly Revenue”.

In a conventional index based search, a search engine will index dataelements and only those elements which have the words “Quarterly”,“Revenue”, or any combinations of the above will show up on the searchresult. This approach doesn't consider the fact that in technicalsystems an element name may be different than a business terminology. Inother words, the corresponding database table that stores the “QuarterlyRevenue” may be called “QTR_SALES_REV” and thus in a conventional indexbased search, the database table QTR_SALES_REV that stored the“Quarterly Revenue” will not be returned.

Therefore, it is desirable to have a system and method to expand aconventional index based search to return greater amounts of relevantdata.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a method according to some embodiments.

FIG. 2 illustrates a system according to some embodiments.

FIG. 3 illustrates a repository according to some embodiments.

FIG. 4 illustrates an apparatus according to some embodiments.

FIG. 5 illustrates a weight table according to some embodiments.

DETAILED DESCRIPTION

The present embodiments relate to a method, apparatus and system toenrich searches with metadata from a metadata repository. Metadata maycomprise data that characterizes other data and may exist in manydifferent places within an enterprise. Metadata may comprise metadatasemantics. The term “metadata semantic” may be defined as inherent rulesand metadata relationships. The term “metadata relationship” may bedefined as the relationships between metadata objects which can beexplicit or implicitly derived from a system. Metadata semantics may beadded to search indexes and thus, a search may be performed on not onlykeyword matching but also on following a plurality of metadata paths(e.g., a graph) of object relationships to reach as many relevantobjects as possible. Each object in the path may be scored and the scorefor each object may determine an object's relevance (e.g., a relevanceof the object to be included in search results). The score may be basedon keyword matching, object relationships and the relationship depth inthe path.

For example, employees' tax identities may be stored in multiple placesin a database and may be used for multiple purposes under differentnames like SSN (social security number in US), SIN (social insurancenumber in Canada), TAX_ID, etc. For auditing purposes, a user may desireto discover each field where tax identities are stored, and what impactmight occur if a change is made to these fields. If a search isperformed based on only keyword matching, the user will need toinvestigate which database tables or views store tax identities bysearching different keywords like SSN, SIN and TAX_ID, and then manuallytrace those keywords to other metadata like reports and business termsthat have relationships with these tables and views and would beimpacted by a change to the searched fields. The present embodiments,using enriched searches with metadata semantics, may perform a singlesearch (e.g., the term “tax identity”) and the search result may containall relevant database tables, views, reports and business terms thatcomprise a high enough relevance score to be included in search resultswhere the relevance score is based on types of objects, relationships,and their depth.

Turning now in detail to the drawings, FIG. 1 is a flow chart thatillustrates a method 100 that may be performed according to someembodiments. The flow chart in FIG. 1 does not imply a fixed order tothe steps, and embodiments of the present invention can be practiced inany order that is practicable. Moreover, the methods may be performed byany of the devices described herein. The method shown in FIG. 1 may beperformed, for example, by the system 200 of FIG. 2 and the apparatus400 FIG. 4. The method 100 may be embodied on a non-transitorycomputer-readable medium.

At 110, a plurality of metadata associated with an entity is received.The plurality of metadata may be transmitted by a metadata engine, suchas, but not limited to SAP's Metadata Management module in SAPInformation Steward.

For illustrative purposes, and to aid in understanding features of thespecification, an example will be introduced. This example is notintended to limit the scope of the claims.

Now referring to FIG. 2, an embodiment of a system 200 is illustrated.System 200 may comprise a metadata engine 240 and a user device 230 incommunication with a server 250. The metadata engine 240 transmitscollected metadata to the server 250. In the present example, themetadata engine 240 may have collected a plurality of metadata semanticsassociated with a system such as database or business application (notshown).

Referring back to FIG. 1, at 120, the plurality of metadata is stored ina repository. A repository may comprise a relational database, a flatfile, an in-memory database, etc. The metadata engine may consolidatemetadata from various data sources and store the metadata into a centralrepository for metadata management. Thus, the repository may includemetadata from various data sources. Continuing with the above example,the metadata engine may consolidate metadata from a database system orbusiness application and transmit that data to the server 250 where theplurality of metadata is stored in a repository, such as, database 220.In some embodiments, the server 250 may comprise the metadata engine240. A search index 260 is built by the metadata engine which iscomprised of metadata in the database 220. The search index 260 is usedby the processor 210 for returning metadata search result to the userdevice.

A search request associated with a data object (e.g., an entity) isreceived at 130, referring back to FIG. 1. Continuing with the aboveexample, a search request for the term “Quarterly Revenue” may bereceived from the user device 230. The search request may be received atthe server 250. A search request may contain one or more keywords for ametadata search.

At 140, search results that comprise a portion of the plurality ofmetadata stored in the repository are determined. The determination maybe based on a search index that has been enhanced with metadatasemantics. In the present embodiments, a search index may be enrichedand augmented with metadata semantics, metadata relationships andbusiness glossary terms. In some embodiments, semantic knowledge may beadded to a search index process or, in other words, each search indexmay be (1) augmented with consolidated metadata which includesdefinition of that element in various contexts such as how that elementis defined in various enterprise systems, (2) augmented with metadataassociated with a parent or child of each entity contained in the searchindex, (3) augmented with various relationships, which are discoveredthrough metadata analysis along with other objects in the enterprisesystems (4) provided with a relationship distance based on objectweighting to determine an relevance of an object in a given context.

Now referring to FIG. 3, an embodiment of a repository 300 isillustrated. The repository 300 may illustrate an example of dataentities that may be stored in a repository 300. The repository 300,illustrated as a table, may list metadata objects which are related to arespective data entity. The repository 300 defines fields 310, 320, 330and 340. Field 310 relates to a data entity name and field 320 relatesto an entity type for an associated entity name. For example, and asillustrated in repository 300, an entity name may be REG_SALES_WEBI.RPTwhich has an entity type of report. Other examples illustrated in therepository 300 comprise an entity name of REVENUE which is a type ofreport field, REV_AMOUNT which is a type database column, andQTR_SALES_REV which is a type database table.

Field 330 may relate to one or more target entities which comprisemetadata objects associated with a respective data entity as listed infield 310. For example, a data entity REG_SALES_WEBI.RPT is related tometadata objects such as QTR_SALES_REV, PRODUCT_SALES, REGIONAL SALESREPORT, REGION, COUNTRY, YEAR, QUARTER, REVENUE, SALES by a relationshiptype which is contained in field 340. As illustrated, QTR_SALES_REV maybe related to REG_SALES_WEBI.RPT through lineage relationship,PRODUCT_SALES is related to REG_SALES_WEBI.RPT through 2 levels oflineage relationship, REGIONAL SALES REPORT is business glossarydefinition associated with REG_SALES_WEBI.RPT, and REGION, COUNTRY,YEAR, QUARTER, REVENUE are each type report field.

The term “business glossary” may be defined as business terms,terminology and concepts that are defined by a business user. Typically,a business user or a data steward may create a business glossary andassociate terms in the glossary to various metadata entities to conveythe meanings, relationships and other aspects. The terms “impact” and“lineage” may be defined as a relationship between a source and targetentity. The target entity may be affected when a change is made to thesource entity. For example, if it is known that a first object impacts asecond object (Obj1→Obj2), then Obj1 has an impact relationship to Obj2,while Obj2 has lineage relationship to Obj1. There may be many levels ofimpact and lineage relationship between two objects. In the case ofObj1→Obj2→Obj3, Obj3 has a “level 2 lineage” relationship to Obj1. It'salso possible that the objects in the relationships may reside inseparate systems.

Continuing with the above example, a search request for “QuarterlyRevenue” may be received at a processor, such as processor 210, theprocessor examines all the search indexes and finds theREG_SALES_WEBI.RPT report because the search index contains a reportfields relationship to QUARTER and REVENUE. Based on the lineagerelationship between REVENUE report field and REV_AMOUNT column, andparent container relationship between REV_AMOUNT column andQTR_SALES_REV table, the QTR_SALES_REV table is returned in the search.The search may also return various other elements from the repository300 that relate to the REG_SALES_WEBI.RPT such as report fields,business glossary definitions, other entities contained in a parentcontainer/folder, other entities that would be impacted (e.g., typeimpact) from the user device 230. The search request may be received atthe server 250.

A semantic and relationship enriched search may find the report field“REVENUE” by simple keyword matching, and a processor may expand thesearch results along the semantics and relationships described in therepository 300 to find the related metadata objects such as the databasecolumn REV_AMOUNT, the report REG_SALES_WEB.RPT, and the table“QTR_SALES_REV”. After that, the search may continue based on objectrelationships and finds a list of business terms. Finally the processormay combine all these different objects, and sorts them based on therelevance score.

The relevance score may be defined as follows:

A search (e.g., a query q) in a document d, which means metadata, may bescored using the following formula:

${{score}\mspace{14mu} \left( {q,d} \right)} = {\sum\limits_{t\mspace{14mu} i\; n\mspace{14mu} q}\left( {{{{tf}\left( {t\mspace{14mu} {in}\mspace{14mu} d} \right)}^{1\text{/}2} \cdot {{idf}(t)}^{2} \cdot}*\left( {\sum\limits_{p\mspace{14mu} i\; n\mspace{14mu} {parents}}{{relationship}\; {f\left( {t,d} \right)}*{{depth}\left( n^{th} \right)}*{{score}(p)}}} \right)} \right)}$

TF may comprise a frequency of the term t. IDF may comprise inversedocument frequency. The score of query q for document d may becalculated on TF-IDF, relationship frequency, depth of an object in arelationship graph, and its related parent objects. TF-IDF may comprisea numerical statistic which may reflect how important a word is to adocument in a collection. Relationship frequency may comprise anothermeasurement that describes how many hidden relationships exist in arelated (indirect) object.

tf(t in d) may relate to a frequency of a term t in a document d. Inorder to avoid bias to large documents tf(t in d) may be normalized to(Frequency of a term t in a document d/total number of terms in adocument) ^(1/2).

idf(t, D) may relate to term t's inverse document frequency that isbased on number of documents containing the term within a collection ofdocument D. It may be calculated as (1+LOG (numDocs/(docFreq+1))) wherenumDocs is the total number of the documents and docFreq is the numberof documents containing the term.

relationshipf (t in d) may relate to a relationship of a document. Itmay be based on a relationship found related to the document d given bya term t within a collection of relationships of document D. The formulais 1+LOG(relationshipWeight*numberOccurs/(totalRelationshipsWeight+1))where relationshipWeight is the weight of a relationship type, andtotalRelationshipsWeight is the sum of number of relationships weight tothe document.

depth(n^(th)) may relate to the level of depth of the object to the topobject.

Since metadata objects may come from various data sources, the types ofrelationships between them may be different. The term relationshipWeightis denoted as the weight of a type of relationship used in the scorecalculation. FIG. 5 illustrates a weight table 500 according to someembodiments. FIG. 5 defines fields 510 and 520. Field 510 relates to atype of relationship and field 520 relates to a weight given to arespective relationship.

A relationship type of “same as” may relate to two objects that are thesame by looking at rules to determine that, even if they have differentnames, the two objects are the same. A relationship type of“parent-child” may relate to a parent-child relationship of objects suchthat a parent may have multiple children but a child may only have asingle parent. A relationship type of “association” may relate toobjects that have some association with each other but to not have aparent-child relationship. For example, two objects may work inconjunction with each other or may comprise a friendship relationship(e.g., social networks). A relationship type of “source-target mayrelate to two objects where one is a source and the other object is atarget of the source object. A relationship type of “business glossary”may relate to business names or user defined relationships.

Some factors used for scoring comprise the following:

tf(t in d) (Frequency of a term t in a document d/total number of termsin a document)^(1/2) idf(t) 1 + LOG (numDocs/(docFreq + 1))relationshipf(t, d) 1 + LOG(relationshipWeight * numberOccurs/(totalRelationshipsWeight + 1)) numDocs The number of all documentsnumberOccurs The number of relationship of this kind to this objecttotalRelationshipsWeight The total weight of relationships to thisobject docFreq The number of document which has the term depth(n^(th))1/the number of the depth to this object score(p) The score of parent

As described above, for a given metadata entity, a search using metadatacombines search indexes from keyword matching and metadata semanticmatching. Metadata semantics may be derived from metadata relationships.An enhanced search index (e.g., keywords as well as metadata) may bebased on a metadata object's name, description and other attributes. Theenhanced search index may comprise metadata semantics and relationshipsand business terms and thus the search index may be based onrelationships which are linked to other related objects. For each typeof relationship, the weight used in the score calculation can bedifferent and configurable. Search results may be limited to anarbitrary number (e.g., 10) and the search results may then betransmitted to a user device.

Now referring to FIG. 4, an embodiment of an apparatus 400 isillustrated. In some embodiments, the apparatus 400 may be associatedwith a server that receives a search request such as server 200.

The apparatus 400 may comprise a storage device 401, a medium 402, aprocessor 403, and a memory 404. According to some embodiments, theapparatus 400 may further comprise a digital display port, such as aport adapted to be coupled to a digital computer monitor, television,portable display screen, or the like.

The medium 402 may comprise any computer-readable medium that may storeprocessor-executable instructions to be executed by the processor 403.For example, the medium 402 may comprise a non-transitory tangiblemedium such as, but not limited to, a compact disk, a digital videodisk, flash memory, optical storage, random access memory, read onlymemory, or magnetic media.

A program may be stored on the medium 402 in a compressed, uncompiledand/or encrypted format. The program may furthermore include otherprogram elements, such as an operating system, a database managementsystem, and/or device drivers used by the processor 403 to interfacewith peripheral devices.

The processor 403 may include or otherwise be associated with dedicatedregisters, stacks, queues, etc. that are used to execute program codeand/or one or more of these elements may be shared there between. Insome embodiments, the processor 403 may comprise an integrated circuit.In some embodiments, the processor 403 may comprise circuitry to performa method such as, but not limited to, the method described with respectto FIG. 1.

The processor 403 communicates with the storage device 401. The storagedevice 401 may comprise any appropriate information storage device,including combinations of magnetic storage devices (e.g., a hard diskdrive), optical storage devices, flash drives, and/or semiconductormemory devices. The storage device 401 stores a program for controllingthe processor 403. The processor 403 performs instructions of theprogram, and thereby operates in accordance with any of the embodimentsdescribed herein.

The main memory 404 may comprise any type of memory for storing data,such as, but not limited to, a flash driver, a Secure Digital (SD) card,a micro SD card, a Single Data Rate Random Access Memory (SDR-RAM), aDouble Data Rate Random Access Memory (DDR-RAM), or a Programmable ReadOnly Memory (PROM). The main memory 404 may comprise a plurality ofmemory modules.

As used herein, information may be “received” by or “transmitted” to,for example: (i) the apparatus 400 from another device; or (ii) asoftware application or module within the apparatus 400 from anothersoftware application, module, or any other source.

In some embodiments, the storage device 401 stores a database (e.g.,including information associated with metadata semantics and metadatarelationships). Note that the database described herein is only anexample, and additional and/or different information may be storedtherein. Moreover, various databases might be split or combined inaccordance with any of the embodiments described herein. In someembodiments, an external database may be used.

Embodiments have been described herein solely for the purpose ofillustration. Persons skilled in the art will recognize from thisdescription that embodiments are not limited to those described, but maybe practiced with modifications and alterations limited only by thespirit and scope of the appended claims.

1-20. (canceled)
 21. A method to enrich search results with metadata,the method comprising: receiving a plurality of metadata associated withan entity wherein the entity is associated with a plurality ofrelationships and relationship types; storing the plurality of metadatain a repository, the plurality of metadata comprising (i) an entity nameand (ii) a plurality of target entities associated with the entity namewherein each respective target entity is associated with a relationshiptype field that indicates a type of relationship between the entity andthe respective target entity; receiving a search request associated withthe entity; and determining search results that comprise a portion ofthe plurality of metadata stored in the repository.
 22. The method ofclaim 21, wherein the repository further comprises a relationship weightfield that indicates a weight for each type of relationship and theportion of the plurality of metadata is based on a score calculationassociated with the weight of each relationship type.
 23. The method ofclaim 21, wherein the repository further comprises an entity type field.24. The method of claim 21, wherein the plurality of metadata isreceived from a metadata engine.
 25. The method of claim 21, wherein theplurality of metadata comprises entities such as a report, a reportfield, a database column, and a database table.
 26. The method of claim21, where the portion of the plurality of metadata is transmitted basedon a score calculation.
 27. The method of claim 21, wherein the entityis a target entity and the metadata is associated with the entity beingaffected when a change is made to a source entity.
 28. The method ofclaim 27, wherein the target entity resides in a first system and thesource entity resides in a second system.
 29. The method of claim 21,wherein the entity is a source entity and the metadata is associatedwith a change to the entity that affects a target entity.
 30. The methodof claim 29, wherein the target entity resides in a first system and thesource entity resides in a second system.
 31. An apparatus comprising: aprocessor; and a non-transitory computer-readable medium comprisinginstructions that when executed by a processor perform a method toenrich search results with metadata, the method comprising: receiving aplurality of metadata associated with an entity wherein the entity isassociated with a plurality of relationships and relationship types;storing the plurality of metadata in a repository, the plurality ofmetadata comprising (i) an entity name and (ii) a plurality of targetentities associated with the entity name wherein each respective targetentity is associated with a relationship type field that indicates atype of relationship between the entity and the respective targetentity; receiving a search request associated with the entity; anddetermining search results that comprise a portion of the plurality ofmetadata stored in the repository.
 32. The apparatus of claim 31,wherein the repository further comprises a relationship weight fieldthat indicates a weight for each type of relationship and the portion ofthe plurality of metadata is based on a score calculation associatedwith the weight of each relationship type.
 33. The apparatus of claim31, wherein the repository further comprises an entity type field. 34.The apparatus of claim 31, wherein the plurality of metadata is receivedfrom a metadata engine.
 35. The apparatus of claim 31, wherein theplurality of metadata comprises entities such as a report, a reportfield, a database column, and a database table.
 36. The apparatus ofclaim 31, where the portion of the plurality of metadata is transmittedbased on a score calculation.
 37. The apparatus of claim 31, wherein theentity is a target entity and the metadata is associated with the entitybeing affected when a change is made to a source entity.
 38. Anon-transitory computer-readable medium comprising instructions thatwhen executed by a processor perform a method to enrich search resultswith metadata, the method comprising: receiving a plurality of metadataassociated with an entity wherein the entity is associated with aplurality of relationships and relationship types; storing the pluralityof metadata in a repository, the plurality of metadata comprising (i) anentity name and (ii) a plurality of target entities associated with theentity name wherein each respective target entity is associated with arelationship type field that indicates a type of relationship betweenthe entity and the respective target entity; receiving a search requestassociated with the entity; and determining search results that comprisea portion of the plurality of metadata stored in the repository.
 39. Themedium of claim 38, wherein the repository further comprises arelationship weight field that indicates a weight for each type ofrelationship and the portion of the plurality of metadata is based on ascore calculation associated with the weight of each relationship type.40. The medium of claim 38, wherein the repository further comprises anentity type field.